Au fil du temps, nous intégrons de plus en plus de contenus, provenant parfois de partis tiers (widgets pour les réseaux sociaux, publicités, etc). Deux conséquences en découlent : les pages web ne cessent de s’alourdir, et nous affichons aux internautes des contenus que nous ne pouvons pas maîtriser complètement.

Certains de ces contenus externes sont intégrés par l’intermédiaire de la balise iframe, et doivent faire l’objet d’une attention particulière en terme de sécurité. Pour limiter les risques, le W3C a ainsi ajouté l’attribut sandbox dans sa spécification du HTML5, qui permet de restreindre les actions possibles dans l’iframe sur les principaux navigateurs récents.

Sandbox : principe

En terme de sécurité, une bonne habitude lorsqu’on fait appel à des éléments qu’on ne contrôle pas, consiste à “cloisonner” l’environnement de ces éléments : on n’autorise si possible que ce qui va être strictement nécessaire, de façon à limiter les impacts éventuels .

L’attribut sandbox a été créé en ce sens, pour limiter les interactions possibles depuis une iframe insérée sur votre page.

Dès lors que vous utilisez cet attribut sur sur une iframe :

<iframe sandbox src=”...”></iframe>

les restrictions suivantes vont s’appliquer :

• Aucun script n’est exécuté, le navigateur se comporte comme s’il ne supportait pas le JavaScript
• les requêtes AJAX ne peuvent être lancées (elle dispose de sa propre “origine”, différente de celle de votre page, et enfreint donc le mécanisme standard CORS respecté par les navigateurs web)
• Vous limitez les capacités de stockage sur le navigateur (utilisation de cookies ou du localStorage impossibles par exemple)
• Il est impossible de créer un nouvelle fenêtre, une popup
• L’envoi de formulaire est interdit
• Les plugins Flash, Silverlight ou encore les applets Java ne sont pas chargés
• L’API Pointer lock, qui renvoit des informations liées aux mouvements de la souris, est bloquée

Lever une partie des restrictions

L’attribut sandbox accepte plusieurs valeurs qui vont vous permettre d’assouplir la politique par défaut selon vos besoins :

• allow-forms : l’envoi de formulaire est autorisé
• allow-scripts : les scripts sont exécutés
• allow-same-origin : l’iframe reprend la même “origine” que la page, et ne fait plus face aux restrictions liées au mécanisme CORS (autorisation des requêtes AJAX, de l’utilisation du localStorage, de cookies…)
• allow-top-navigation : l’iframe peut à nouveau accéder à la page parente
• allow-popups : l’ouverture d’une nouvelle fenêtre/d’une popup est possible
• allow-pointer-lock : l’API Pointer Lock est exploitable

Notez que vous ne pouvez pas autoriser de nouveau l’exécution de plugins.

Prenons le cas de l’intégration d’une iframe qui souhaite ouvrir une popup vers un service tiers, et demander une authentification pour accéder à ce service. Les attributs à ajouter seront :

• allow-popup pour autoriser l’ouverture de la popup
• allow-same-origin pour permettre l’authentification et le stockage de cookies
• allow-forms pour autoriser l’envoi du formulaire d’authentification au sein de la popup (car la restriction s’applique à l’iframe, mais aussi aux éléments qui en découlent)

<iframe sandbox=”allow-same-origin allow-forms allow-popups” src=”...”></iframe>

À noter qu’il est déconseillé d’ajouter à la fois les valeurs allow-scripts et allow-same-origin : en autorisant ces 2 valeurs, vous permettez à l’iframe d’accéder et de modifier votre arborescence DOM. Dans ce cas, une iframe malveillante pourra effectuer toutes sortes d’opérations, pouvant même supprimer son propre attribut sandbox !